上一篇文章介紹了 ISO 27001 這個工作本身， 以及透過一個實際的改善項目來讓大家了解整個過程。 每次稽核過後，都會出現一連串的改善事項，在要求的時限內一個一個完成這些改善事項，就會是 ISO 27001 的全貌。像是之前提到過的〈特別監控系統2: 資料庫異常登入監控〉也是屬於其中一種。資料庫因為是營運上的關鍵系統，因此需要監控，此外服務後台 (CMS) 的異常登入實際上也是監控重點之一，但因為該系統的監控在架構和概念上與資料庫這裡的設計雷同，因此就沒有特別放在鐵人賽當中。
雖然改善事項通常是一個完成之後就算是結束的工作，但也會有一些只要想保有這個證照，就會需要定期檢視的任務。比如定期盤點營運關鍵系統的 CPU 或 memory 使用量等等。針對類似的工作，產品經理通常會每隔一段固定的時間(比如一個月或一季)就會來提醒我們盤點的事宜，而我們則是透過截 CloudWatch 上面的圖來回應。因為一般狀況下系統都不會有什麼太大的問題，因此 CPU 的使用量都是處在健康的狀態，透過像這樣子的截圖來達到定期檢視的要求。
另外一個要定期執行的任務則是模擬重大 P0 事件的解決流程。雖然在〈系統警報概論〉中曾有提到過， 我們一直都有一套固定的緊急事件應對流程，但在事情發生的當下是否能夠確實針對事件做出合理的處置，則仍然是一個未知數。特別是在承平時期，如果系統長時間沒有任何狀況，那即使應對流程足夠完善，實際的操作者也可能因為已經忘記流程，而導致緊急事件的當下無法有效處理。
因此，我們每一年都會選擇一個時間來模擬重大 P0 事件發生當下的緊急處置。透過一個 P0 事件的劇本，事先安排各個職位的角色，完成這次事件的演出之後，再進行檢討會議來確認改善事項。
從以上的定期事物看得出來，因為許多工作已經變成是日常定期舉辦的事項了，因此從這個角度來看， ISO 27001 也不單純是一個單一事件，也可以看作是一個日常維運工作了。
在之前有稍微向讀者分享過，因為敝公司目前還沒有比較專門的資安單位的關係，因此一些 ISO 27001 中與資安相關的工作就落在了 SRE 身上。處理這些不熟悉的任務本身也是學習的一環，但是一來 SRE 比較會從維運穩定性的角度出發，因此可能容易產生資安角度的盲點；另一方面 SRE 原本的人力配置本來就不足以應付額外的資安工作。因此在這個地方就容易產生一些需要溝通協調的部分。
以「資安異常行為」這類事情為例， SRE 從維運的角度來看，有可能會傾向於覺得從權限的角度來控管，透過完整的權限規劃來避免使用者做出超出他們權限範圍的行動即可。但從另一個角度來看， 即便在做出完整的權限規劃之後，仍然應該要進一步針對沒有授權的行動進行監控。在無授權行動出現的時候，發送緊急通知給相關的權責單位。
上面這一段聽起來非常合理，但是在實施上面卻會需要非常充分的人力配置才有可能達成。因為光要盤點沒有授權的行動本身，就已經有可能會需要花上大量的時間和人力，更不用說還要針對這些行動掛上監控系統。
此外， ISO 27001 在許多改善事項上，反而是要求我們要自己提出相關的改善方式或細節。比如密碼複雜度的設定上，並沒有一套規則要求比如密碼的長度之類的，反而是我們要自己制定。這當然其實是一個非常合理的規則，因為每個系統有各自的特點，會遇到的問題也不盡相同，因此在這邊保有讓系統管理者自己決定的彈性也是可以理解的。
但上面這些事務每一項都是一個需要花時間處理的工作，而且同時間也有其相當程度的專業性。因此在人力吃緊的情況之下，有時候就會需要透過更多的溝通或協商來達到能夠符合要求，但又可以有效利用現有資源的方式。比如說， AWS 的資安工具雖然非常方便，但有時候會因為掃描出預期之外的東西，而反而改採用比較人工的方式來解決問題。雖然一切從簡，但還是能夠符合 ISO 27001 的要求。
雖然說了這麼多的工作，但我們還是成功地拿到 ISO 27001 的證書了。
這個工作絕對是一個需要花費大量人力與時間成本的工作，也並非一朝一夕可以完成的任務。
從這兩篇介紹的文章中也可以看出來，除了技術上的切入點外，各種非技術的問題也會在這種大型任務中浮出水面。這也與筆者從一開始就想要分享的心態一樣，就是 SRE 是一個不只技術能力重要，溝通或其它軟實力也同樣非常重要的工作。
下一篇開始會介紹另一個重要事件，關於我們更換 CDN 廠商的事件。
iThome鐵人賽
看影片追技術